As used herein, IP data packets refer to data packets containing IP source and/or destination addresses. Typically, IP data packets are routed from source to destination through a series of routers which receive the IP data packet, read the source and/or destination address and re-transmit the IP data packet either to its destination as indicated by the IP destination address contained therein, or to another router which will forward the IP data packet further along until the IP data packet reaches its destination. Each of these intermediate steps between router and destination are referred to as a "next hop." Through the use of a routing look-up table, the router must determine: (i) the output interface port, of which it may have more than one, through which to forward the data packet; and (ii) the "next hop" for that data packet from the node connected to that interface. The combination of output interface and next hop is referred to as the route.
Since there are typically more than one route that will ultimately lead an IP data packet to its destination, prior to routing the data packet, the router must learn the set of addresses to which the IP data packet may be forwarded. Typically the appropriate route for a given IP address is encoded in part or all of the IP address itself. For example, for a 32 bit IP address, the first 16 bits, from left to right, i.e., the route prefix, may be used to indicate the appropriate route to reach that destination. Contained within the route prefix is a subnet mask. The subnet mask indicates with a 1, which of the first eight bits, for example, are significant, and with a 0, which are insignificant.
For example, a route prefix may be represented in hexadecimal format as 12345678 and FFFFF000, where FFFFF000 is the subnet mask. In this case the subnet mask indicates that only bits 12345 are significant. Therefore, the set of addresses appropriate for the route of this IP data packet ranges from 12345000 to 12345FFF.
The next step for the router is to find a route that corresponds to any of the addresses within this set of addresses. It should be apparent that since there are a range of addresses the router may find more than one route that matches an address for this IP data packet. The router's task is to find the best route, defined by the address that has the most bits in common with the IP data packet's destination address. Thus, continuing with the above example, a route matching address 123457 is not as good as a route matching address 123456.
Traditionally, a router look-up operation is performed in linear fashion. Each entry in a look-up table is examined for a match. The operation must continue throughout the table even after a match is found to be certain that the best match was found. Since a router look-up table may have from 30,000 to a few hundred thousand entries, this process is time consuming. As a result, routing table look-up operations are the performance bottlenecks of high-end routers which can have throughput of around 2 Gbps. To eliminate this bottleneck, the router must be able to perform more than four million look-ups per second.
Several proposals have been suggested in the art to reduce or eliminate the performance bottleneck of the router look-up operation. One such proposal is known as Practical Algorithm to Retrieve Information Coded in Alphanumeric ("Patricia"), and employs a radix tree referred to as the PatriciaTree. Referring to FIG. 1, a binary tree is constructed from the information contained in the look-up table (not shown). Each node of the tree examines a different one of the bits of the route prefix and has a link to either two children nodes or no children nodes. For example, root node 15 examines bit number 20 and has children nodes 16 and 17. A node with no children nodes is referred to as a leaf node, node 17, and contains a pointer to a complete route prefix and an associated route stored in RAM 10. For additional information on the Patricia Tree and its construction, see G. R. Wright and W. R. Stevens, "TCP/IP Illustrated, Volume 2," Chap. 18 (1995), hereby incorporated by reference as if fully set forth herein.
Since there are up to two children nodes per parent node, we refer to left and right paths of the router respectively, as the router traverses the tree from parent to one of the children nodes. Thus, if the subject bit of the parent node is a 0, the router will examine the subject bit of node 11, lying on the left path. Similarly, if the subject bit is a 1, the router will examine node 17, lying on the right path. This continues until a leaf node is reached, at which point a comparison is made between the route prefix of the IP data packet and the route associated therewith. A match in a leaf node is considered the best match and therefore the remaining routes do not need to be searched. If, however, there is no match at the leaf node the router must backtrack along the tree. In FIG. 1 this is shown by the arrow path traversing nodes 16-18-16-19.
While this method supports subnet masks, large numbers of route entries, and eliminates the necessity in many cases to search each route entry, it can require, in a worst case scenario, h.sup.2 iterations where h is the height of the tree and can be as large as the entire IP address.
A second proposal that addresses the router performance bottleneck is known as Content Addressable Memory ("CAM"). Referring to FIG. 2, CAM 25 is employed to cache the results of routing table look-up operations. Given an IP address 20 a CAM can parallel search its entries for a match. If there is a match a pointer is emitted to find the output interface and other information from RAM 28. While a CAM is efficient in search speed, it is expensive and small in capacity as compared to regular RAM. Moreover, since a CAM can only perform searches on whole IP addresses, it does not naturally support subnet masks.
Because of these drawbacks and because CAM can only support a relatively small number of entries, other proposals employ a combination of CAM and other methods. Yet, the use of CAM remains expensive and inefficient due to its lack of support for subnet masks.